I finally got around to book my (train) trip back from Zagreb. The hotline of Deutsche Bahn was interesting. The booking system crashed and I was called back. But in the end it worked and I can print it the next time I get near a vending machine.

I'm worried how I manage to get there from Banja Luka on my own. And the travel to Zagreb together with Joachim Breitner won't be as comfortable as it should be. But meh, I'm going to DebConf again! \o/

I just posted a call for testing to the not yet well-known debian-stable-announce mailing list. Please test the packages in squeeze-proposed-updates on some stable machines if possible, so that we don't screw up your production machines with bad updates in a week. The point release is scheduled for June 25th, i.e. next Saturday. Don't forget to copy the debian-release mailing list when you encounter regressions. Thanks for your efforts.

So Christian likes to give out awards for the best bug reporting estimates and also does statistics about developers per capita. I've got at least one area where he's on top:

The award for the introduction of the highest version into the archive goes to Nicolas Spalinger and Christian Perrier for ttf-sil-gentium. The use of a date as an epoch is amazing. The runner-up is Joey Hess with intercal (soon to be gone from Debian altogether), reusing the version number in the epoch. Somehow that fits with the crazy language the package contains.

The award for the most minimal version goes to Guido G nther with libvirt-glib. It's a number less than zero but still not negative. The runner-up is Raphael Geissert with switchsh which just happens to use 2007 as a checkout date.

Philipp is a Debian developer since 2005 and a member of the release team since 2008. Since he took the responsibility of Stable Release Manager, the process has evolved for the best. I asked him to explain how the release team decides what s fit for stable or not. His work on the buildd infrastructure is also admirable but I ll let him describe that. My questions are in bold, the rest is by Philipp. Who are you? I m a 24 year old Computer Science student, living in Karlsruhe, Germany. As a student assistant I m currently in two jobs: one is taking care of getting our university IPv6 network in shape, or rather generally getting fringe technologies into the network. The second is taking care of a s390x machine in the basement which my faculty got sponsored recently. In my spare time I tend my Debian duties and I m active in the student council (Fachschaft) as a sys-admin, software developer and until recently as treasurer. I got accepted as a Debian Developer in 2005. I m only really active since I was invited to join the Release Team in early 2008 after I contributed rewrites of some scripts that got lost in a disk crash of ftp-master. In late 2008 I also took on wanna-build/buildd duties. What s your notable achievement within Debian? For one I worked on the deployment of a single buildd/sbuild combination over all of our buildds and I rebased it on the sbuild in the archive several times already. All buildds basically look the same on all architectures, with only few variations. The chroots are now also created in a mostly predictable manner. Then we finally got build autosigning after years of constant poking. However the policy decision to allow it was made by the ftp-masters anyway, for which I m grateful, as it eases the workload of the buildd maintainers, the Security Team and the Release Team quite a bit. On the release side there s the integration of volatile into the proper structures of Debian. But there I m guilty for choosing the bad name squeeze-updates is, in comparision with security s squeeze/updates. Let s see if we can improve that for wheezy. The policy for stable updates have changed over time. Can you summarize what kind of updates are allowed nowadays? All the changes that were made to the policy were driven by the aim to keep stable (and to some lesser degree oldstable) usable throughout its lifetime. I have to admit that we got slightly more liberal in what we accept since I took over. The previous stable update policy included the fixes of critical bugs that break the system in interesting ways and security fixes. We also opened up the possibility of including important fixes for annoying bugs on a case-by-case basis. The whole don t update that much part of the stable release management is rooted in let s don t change the behaviour of a running system and let s have as few regressions as possible . We currently try to counter that with a review process that only allows self-contained fixes that were tested in unstable first, if applicable. In the future I d also like to have a feedback process that includes the users of the packages to report problems more early. In fact that s also why we now send calls for testing to debian-stable-announce one week in advance (see this mail as an example). So stable is updated through point releases that happen roughly every two months for stable and roughly every four for oldstable. They are accompanied by announcements and new CD/DVD sets. To be able to push some updates with less delay to our users and to avoid that they have to pick them from proposed-updates, there is stable-updates. The current policy for this suite is available in this post on debian-devel-announce. It boils down to everything urgent like tzdata, regression fixes and volatile packages. We noticed that some packages in stable just weren t useful anymore when they got updated through volatile. Hence those are folded into stable, too. We also relaxed the rules a bit so that leaf packages like clive, that rely on external websites not to change their URLs, can be updated too. If somebody wonders what happened to the and a half releases Those were intended to mark the inclusion of new hardware support (mostly by including a co-installable new kernel version). This kind of flag point release is thankfully no longer needed because our marvellous kernel team now backports certain hardware drivers to the kernel version in stable. They have some trouble soliciting test feedback for them, though. It would be cool if more people using stable could respond to their calls for testing. What are your plans for Debian Wheezy? Luckily the wanna-build/buildd side isn t much dependent on release cycles. The stable release management also just takes care of what gets dumped on them by the testing RMs. The near-term goals are certainly:

• getting d-i to use some development process in the archive that s compatible with the normal flow of packages into testing and
• hopefully getting wanna-build to use a sane SQL layout and hence better performance

Apart from that my work is mainly squashing the bugs on buildd.debian.org for the wanna-build part, so if you want something fixed, you need to report it, I m afraid. You have several roles within Debian, in particular stable release manager and member of the wanna-build team. Which role do you enjoy more and why? So the regular duties of the SRM, apart from setting up policies, are reviewing requests for uploads to proposed-updates, accepting them, chasing builds and scheduling point releases. It s mainly steady work. As for the Release Team it s working in a fabulous team where everyone s doing an awesome job. For me the wanna-build role is holding the things together and fixing up stuff that breaks while the world continues to evolve. And occassionally taking a stab at the ftp-masters. So rather different. My heart is probably siding with the buildd side because it s infrastructure but release work is fun, too. What s the biggest problem of Debian? Mainly that we re not quick in picking up new technologies and that we got slow on innovation. Distro-wide changes are usually a very big effort to coordinate and to finally complete. I guess people should be able to push fixes for release goals more eagerly into the archive. Also it seems to me that many DDs are actually disengaging from the release process, especially during the freeze but also before, which makes me a bit sad. However I m still not sure how we could counter that. As we re all volunteers you can t suddenly make others love the idea of releasing something together, I guess. Do you have wishes for Debian Wheezy? It s getting old, but there s certainly multiarch. Also a usable Python 3 is something I d really appreciate. Is there someone in Debian that you admire for their contributions? Peter Palfrader did an awesome job of getting a nicely working team together for DSA and got many tasks as automated as they are now. It s a pleasure to work with them and setting up a new buildd is, for example, a real breeze. He also developed a sane archive snapshot service, kudos for that.

---

Thank you to Philipp for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

• Ben Hutchings reported that older Lenny CDs do not actually install anymore. As we are still telling people that they don't need to throw away old CDs this was a tad disappointing to me. Got myself a 5.0.0 disc through jigdo and cdimage's fine snapshot service for packages that aren't actually in (old)stable anymore. Using a network mirror during installation is apparently the default (although you can decline it). Doing so will try to go to the security mirror and try to upgrade the base installation it just expanded from the debs on the CD. As the archive signing key changed recently, this leads to apt moaning about untrusted packages, which isn't actually exported to the debian-installer UI. The installation just hangs in "Select and install software" with a prompt being displayed on tty4. Mark Hymers agreed that it makes sense to switch the Release signature for lenny-security back to the old key for the time being and called for objections on debian-devel. Doing so should fix installation for oldstable users with old CDs again. In the future d-i should upgrade debian-archive-keyring first before the security archive's contacted and I've filed a bug report about that (#619751).
• Closed some old crufty bug reports on the pseudo package buildd.debian.org that were either already solved or easy to solve. (#607619, #602841, #586882, #520479, #507153, #605285)
• Scripted the generation of keys to get the initial batch of them done. 27 machine keys have been generated so far, with the exception of some machines that are currently down or lack entropy (like the kfreebsd-* ones which aren't fed by the keys). The keys are already activated on the archive side. s390, half of powerpc and some amd64 already run with autosigning turned on. armel will follow tomorrow thanks to Riku Voipio. We'll get more coverage soon, I bet.
• Fixed up retry as an answer to the build log. There are two possible actions that a buildd admin can do when he received a log: retry and give-back. The former will cause a build retry on the same buildd it was tried before. The latter will give it back to wanna-build to reschedule it. Due to the way retry is implemented you cannot retry binNMUs, though. There's #524547 filed against buildd about that. (There's still no support to schedule a build on a specific set of buildds neither.)
• Fixed up a typo in the wanna-build trigger for the main archive that caused double builds when we manual re-run it instead of being pushed by the archive.
• Thought about how to use Packages-arch-specific properly from WB::QD (our Perl-ish quinn-diff replacement). Currently the handling of annotations like "!linux-any" is broken because the logic does not account for architecture wildcards (besides of "any" which is special ). Luckily there's some sort of test suite, which I already adapted locally, but the code isn't really the best to read at the moment. So that's still on my to-do list to solve #603762.
• There's a post on arch:all autobuilding not happening just yet pending in the queue. I hope to get it out tomorrow or the day after.

Proposals for autosigning were floating around for quite some time. The most controversial parts were how we secure the machines that do the building (and in turn: how do we secure the key) and who's going to manage the keyring (because there are multiple teams involved; such discussions can indeed take quite a bit time).

What we've agreed upon now is as follows:

• All buildds with autosigned must be debian.org machines, which means that they are administrated by the Debian Sysadmins. This involves regular upgrades of the machine, firewalling and monitoring. They are all doing this already (kudos!), so there was no change needed.
• The machines must be restricted so that only a limited set of people may access it. That's done, it's just the buildd admins for the specific buildd and the global group builddadm (plus the admins and the local admin, of course).
• Every host has its own GPG key. Key generation locally on the buildds is eased by having the fine Entropy Key hooked up to provide entropy centrally and distributed to the debian.org machines. Private keys don't need to and must not leave the host. The keys are rotated every 120 days, expiry dates will be used to ensure that and to remind us when rotation is due. Sadly there is no HSM involved. Given the geographic dispersiveness of the Debian infrastructure that's not done easily. Some machines (like s390 racks) would also be unable to connect local hardware.
• The keys are restricted to specific architectures. They are not able to upload any source to the archive. However every binary on the specific architecture can be uploaded using the key, there are no further restrictions on package priorities or the like. They are maintained by the wanna-build admins on ftp-master by signing the armored public keys with their personal GPG keys (instructions available on the list). Thus a trust chain is established: who added or removed which key and when.
• We plan to suppress networking in the chroot soon. This will possibly be done with unshare(1) in util-linux, as soon as we sort out proper localhost networking. This was not deemed a blocker at this point.

Mehdi is a Debian developer for a bit more than a year, and he s already part of the Debian Release Team. His story is quite typical in that he started there by trying to help while observing the team do its work. That s a recurrent pattern for people who get co-opted in free software teams. Read on for more info about the release team, and Mehdi s opinion on many topics. My questions are in bold, the rest is by Mehdi (except for the additional information that I inserted in italics). Who are you? I m 27 years old. I grew up in Ariana in northern Tunisia, but have been living in Paris, France, since 2002. I m a PhD Student at the PPS laboratory where I study synchronous concurrent process calculi. I became interested in Debian when I saw one of my colleagues, Samuel Mimram (first sponsor and advocate) trying to resolve #440469, which is a bug reported against a program I wrote. We have never been able to resolve it but my intent to contribute was born there. Since then, I started to maintain some packages and help where I can. What s your biggest achievement within Debian? I don t think I had time to accomplish a lot yet I ve been mostly active in the OCaml team where we designed a tool to compute automatically the dependencies between OCaml packages, called dh-ocaml. This was a joint work with St phane Glondu, Sylvain Le Gall and Stefano Zacchiroli. I really appreciated the time spent with them while developing dh-ocaml. Some of the bits included in dh-ocaml have been included upstream in their latest release. I ve also tried to give a second life to the Buildd Status Pages because they were (kind of) abandoned. I intend to keep them alive and add new features to them. If you had a wand and could change one thing in Debian, what would that be? Make OCaml part of a default Debian installation But, since I m not a magician yet, I d stick to more realistic plans:

1. A lot of desktop users fear Debian. I think that the Desktop installation offered by Debian today is very user-friendly and we should be able to attract more and more desktop users. Still, there is some work to be done in various places to make it even more attractive. The idea is trying to enhance the usability and integration of various tools together. Each fix could be easy or trivial but the final result would be an improved Desktop experience for our users. Our packaged software run well. So, each person can participate since the most difficult part is to find the broken scenarios. Fixes could be found together with maintainers, upstream or other interested people.
   
   I ll try to come up with a plan, a list of things that need polishing or fixes and gather a group of people to work on it. I d definitely be interested in participating in such a project and I hope that I ll find other people to help. If the plan is clear enough and has well described objectives and criteria, it could be proposed to the Release Team to consider it as a Release Goal for Wheezy.
   
   
2. NMUs are a great way to make things move forward. But, sometimes, an NMU could break things or have some undesirable effects. For now, NMUers have to manually track the package s status for some time to be sure that everything is alright. It could be a good idea to be auto-subscribed to the bugs notifications of NMUed packages for some period of time (let s say for a month) to be aware of any new issues and try to fix them. NMUing a package is not just applying a patch and hitting enter after dput. It s also about making sure that the changes are correct and that no regressions have been introduced, etc
   
   
3. Orphaned packages: It could be considered as too strict and not desired, but what about not keeping orphaned and buggy packages in Testing? What about removing them from the archive if they are buggy and still unmaintained for some period? Our ftp archive is growing. It could make sense to do some (more strict) housekeeping. I believe that this question can be raised during the next QA meeting. We should think about what we want to do with those packages before they rot in the archive.

[Raphael Hertzog: I would like to point out that pts-subscribe provided by devscripts makes it easy to temporarily subscribe to bug notifications after an Non-Maintainer Upload (NMU).] You re a Debian developer since August 2009 and you re already an assistant within the Release Management team. How did that happen and what is this about? In the OCaml team, we have to start a transition each time we upload a new version of the OCaml compiler (actually, for each package). So, some coordination with the Release Team is needed to make the transition happen. When we are ready to upload a new version of the compiler, we ask the Release Team for permission and wait for their ack. Sometimes, their reply is fast (e.g. if their is no conflicting transition running), but it s not always the case. While waiting for an ack, I used to check what was happening on debian-release@l.d.o. It made me more and more interested in the activities of the Release Team. Then (before getting my Debian account), I had the chance to participate in DebConf9 where I met Luk and Phil. It was a good occasion to see more about the tools used by the Release Team. During April 2010, I had some spare time and was able to implement a little tool called Jamie to inspect the relations between transitions. It helps us to quickly see which transitions can run in parallel, or what should wait. And one day (in May 2010, IIRC), I got offered by Adam to join the team. As members of the Release Team, we have multiple areas to work on:

1. Taking care of transitions during the development cycle, which means making sure that some set of packages are correctly (re-)built or fixed against a specific (to each transition) set of packages, and finding a way to tell Britney that those packages can migrate and it would be great if she also shared the same opinion. [Raphael Hertzog: britney is the name of the software that controls the content of the Testing distribution.]
2. Paying attention to what is happening in the archive (uploads, reported RC bugs, etc ). The idea is to try to detect unexpected transitions, blocked packages, make sure that RC bug fixes reach Testing in a reasonable period of time, etc
3. During a freeze, making sure that unblock requests and freeze exceptions are not forgotten and try to make the RC bug count decrease.

There are other tasks that I ll let you discover by joining the game. Deciding what goes (or not) in the next stable release is a big responsibility and can be incredibly difficult at times. You have to make judgement calls all the time. What are your own criteria? That s a very hard to answer question (at least, for me). It really depends on the case . I try to follow the criteria that we publish in each release update. Sometimes, an unblock request doesn t match those criteria and we have to decide what to accept from the set of proposed changes. Generally, new features and non-fixes (read new upstream versions) changes are not the kind of changes that we would accept during the freeze. Some of them could be accepted if they are not intrusive, easy and well defended. When, I m not sure I try to ask other members of the Release Team to see if they share my opinion or if I missed something important during the review. The key point is to have a clear idea on what s the benefit of the proposed update, and compare it to the current situation. For example, accepting a new upstream release (even if it fixes some critical bugs) is taking a risk to break other features and that s why we (usually) ask for a backported fix. It s also worth noticing that (most of the time) we don t decide what goes in, but (more specifically) what version of a given package goes in and try to give to the contributors an idea on what kind of changes are acceptable during the freeze. There are some exceptions though. Most of them are to fix a critical package or feature. Do you have plans to improve the release process for Debian Wheezy? We do have plans to improve every bit in Debian. Wheezy will be the best release ever. We just don t know the details yet During our last meeting in Paris last October, the Release Team agreed to organize a meeting after Squeeze s release to discuss (among other questions) Wheezy s cycle. But the details of the meeting are not fixed yet (we still have plenty of time to organize it and other more important tasks to care about). We would like to be able to announce a clear roadmap for Wheezy and enhance our communication with the rest of the project. We certainly want to avoid what happened for Squeeze. Making things a bit more predictable for developers is one of our goals. Do you think the Constantly Usable Testing project will help? The original idea by Joey Hess is great because it allows d-i developers to work with a stable version of the archive. It allows them to focus on the new features they want to implement or the parts they want to fix (AIUI). It also allows to have constantly available and working installation images. Then, there is the idea of having a constantly usable Testing for users. The idea seems nice. People tend to like the idea behind CUT because they miss some software disappearing from Testing and because of the long delays for security fixes to reach Testing. If the Release Team has decided to remove a package from Testing, I think that there must be a reason for that. It either means that the software is broken, has unfixed security holes or was asked for the removal by its maintainer. I think that we should better try to spend some time to fix those packages, instead of throwing a broken version in a new suite. It could be argued that one could add experimental s version in CUT (or sid s) but every user is free to cherry-pick packages from the relevant suite when needed while still following Testing as a default branch. Besides, it s quite easy to see what was removed recently by checking the archive of debian-testing-changes or by querying UDD. IMO, It would be more useful to provide a better interface of that archive for our users. We could even imagine a program that alerts the user about installed software that got recently removed from Testing, to keep the user constantly aware any issue that could affect his machine. About the security or important updates, one has to recall the existence of Testing-security and testing-proposed-updates that are used specifically to let fixes reach Testing as soon as possible when it s not possible to go through Unstable. I m sure that the security team would appreciate some help to deal with security updates for Testing. We also have ways to speed migrate packages from Unstable to Testing. I have to admit that I m not convinced yet by the benefits brought by CUT for our users.

---

Thank you to Mehdi for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

Gobby 0.5 (or to be more precise 0.4.92) just hit the Karmic Koala. Below you can see a screenshot of the new version (just click on it to get a large version). It is sadly not protocol compatible to the old version but it features local undo and redo! Furthermore it's not yet stable on-the-wire wise. The software itself is fairly stable but it could be a bit bumpy if the server protocol version goes out of date. If you want to try it out on earlier versions, I offer backports in the Infinote PPA for Intrepid and up. I hope to get to Hardy soon, sadly it needs some more backports. There is a public server available on gobby.0x539.de if you want to try it out (connections are encrypted, but all contents are public and can be deleted by everybody, wiki-like; so please be considerate and non-destructive). On local networks Gobby will look for servers through Avahi. That said Gobby is not yet able to host servers by itself, like the old version did. You have to install the infinoted server. You can do this on any computer, even on the local network and take advantage of Avahi. If you want encrypted connections you need to create certificates but if an unencrypted session is acceptable you can get an ad-hoc server by invoking infinoted --security-policy=no-tls without further configuration. It will persist content across invocations, too. Thanks to Greg Heynes, there will also be a KDE client for Gobby, called... Kobby! The first time someone actually uses the fact that the software uses a library for interoperability. Interesting that it's done now when the library's C instead of C++ (which obby was written in), with Qt being C++ anyway. I'm not yet aware of packages but I really hope that we can release with both. If you encounter problems, please report them to our Trac (preferred) or Launchpad.

Lenny got released yesterday and after having to push another update to Etch through volatile to fix an annoying warning when Lenny is in the sources.list, my work is now almost done too. (Yes, the autobuilding infrastructure is still offline, but we will get that reactivated shortly.) Anyway: if you live in or around Karlsruhe and did not get a mail by nomeata and me and if you would enjoy meeting tomorrow (Monday) evening, please speak up by mailing us. Let us celebrate the latest and greatest release. ;-) The plan is to meet up at the Vogelbr u at 19:30.

It is a shame that the bug count for Lenny is only rising since the beginning of Debcamp (about 2008-08-02). Fellow developers, do you really want to release? Is the Release Team expected to fix all the bugs you file?

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

Dear Lufthansa, please do not mess with my flights! (Link Germany-only, sorry; title says it all, anyway...)

I got my Freerunner on Saturday and my first impressions are somewhat divided. It works, basically, sometimes. It suspends correctly, but when I leave the phone on over night, it won't wake up again. It is still logged into GSM, but neither USB networking nor the buttons on the side work. Problem no. 2 is that pulseaudio goes into lock-up mode (i.e. wasting a load of CPU cycles, doing nothing), which basically means that you cannot call anymore (and of course, you don't get a ringtone neither, but it still vibrates). At least you can get to this point flashing newer software images. It is shipped with a very minimalistic software set, and even with the newest daily openmoko-devel image (less of the two evils, with qtopia being half-baked) one misses a utility to set (basic) preferences. Well, but SSH works and some things could just be hacked around. If you don't want to invest time into getting your phone to work get something else. ;-)

I think I'm ready to go to Debconf 8 now. Just got the last missing vaccination of ones recommended for visitors of Argentina (link German, sorry). Also signed up for an insurance in case I get sick. Now I just need to prepare my stuff properly and restock some of the drugs I occassionally use, just in case. I still feel a bit inert, but I guess that it will be a nice trip and experience. Thanks to those who made it possible!

Some months ago I didn't think that I would stick to an English TV series, not in any way dubbed or subtitled. But my girlfriend got me totally hooked up with both House, M.D. (Hugh Laurie is just hilarious) and 24. I got my own pick, too: Futurama. At least watching those American series improves my listening comprehension, although I still miss quite a lot of puns and jokes due to the missing subtitles and due to my missing knowledge of English sayings. But it works out somehow, she's explaining some of them to me, and I still enjoy it and have fun.

Because I found it a tad non-obvious here a little tutorial. First we enable serial access to grub. For this add the following to your /boot/grub/menu.lst (tested with Grub legacy):

serial --unit=0 --speed=19200
terminal --timeout=5 serial console

I chose such a low baud rate because it worked and I didn't want to spend more time on it and because the highest baud rate (115200) had some timing problems with that specific configuration. Then we need to adjust Xen to send the hypervisor output to the serial console as well (again in /boot/grub/menu.lst, this probably applies this way to Debian only):

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=com1=19200,8n1 console=com1,vga sync_console

Debian's update-grub uses the comments in the file to generate appropriate menu entries, even if the kernel and hypervisor versions change. Thus editing a comment works, but you must remember to call update-grub after your changes, otherwise they won't be active! The last thing to change is the kernel's console. You might specify multiple consoles on the kernel's command line but only the last one will be the primary where the boot messages from init and the boot scripts are sent to. Kernel messages will end up on both, however. The edited comment looks like this (without Xen you would change kopt instead):

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0 console=ttyS0,19200n8

The key change which enabled me to use the serial console was passing sync_console to Xen. Sadly it complains now on boot that this option should not be used on production systems because it ensures that all messages reach the serial console and wait if necessary. But in my humble opinion it should only hurt on output and there should not be that much kernel and hypervisor output anyway, except if there is something wrong with the machine. Serial output from Linux only was also messed up when Xen hadn't this option activated. To access the serial console just invoke GNU screen as a user in group dialout or as root like this to get the serial console as screen's first window:

# screen /dev/ttyS0 19200

Now the only thing that's missing is an affordable remotely controllable power line to trigger power cycles... Update: Liberie Cunha-Neto kindly pointed me to the Xen hypervisor command line, from which one could reboot the machine. It is invoked by pressing Ctrl-a three times on the serial console (it does not work on the real one I told). In screen you need Ctrl-a, a instead, as Ctrl-a is its command prefix. Then you can get help by pressing h and reboot the machine by pressing R.

This will be my first DebConf ever and I'm excited. I just booked my flights together with nomeata:

2008-08-03: Frankfurt (10:20) -> Buenos Aires (19:05) [LH510]
2008-08-03/04: Buenos Aires (21:30) -> Mar del Plata (3:20) [Bus]
2008-08-17: Mar del Plata (12:00) -> Buenos Aires (18:00) [Bus]
2008-08-18: Buenos Aires (20:55) -> Frankfurt (15:00) [LH511]

Yesterday I got a note from the Debconf organizers about my place in the sponsorship queue (15 of 58). The drawback, however: there is no money to be given out, yet. At least that's what I heared on IRC. The mail sounds a tad different. Considering that I applied for 2300 USD (~1300 EUR) there is no way that I pay this alone, being a job-less full-time student spending the other time with volunteer work. It would be nice to meet up all the other people driving Debian (apart from those I already met at FOSDEM), but considering that I wouldn't even see much of Argentina, well: no. Flights aren't getting cheaper, too. Back then when I searched (February I guess) Lufthansa return flights were offered for 1000 EUR flying non-stop from Frankfurt. I don't might paying a few hundred dollars on this myself, but how are other non-company-sponsored individuals dealing with this notice? (Comments are enabled, but need OpenID. Comments mailed in will be converted if allowed to do so.)

We escorted Sarge to its last home. 3.1r8 is done, thanks to all the people who made it possible. A big thanks goes to James Troup, our ftpmaster of the day doing all the grunt work of getting a new point release out of the door. To bring in a more personal feeling of who makes this all possible, here is a list of people contributing uploads to 3.1r8 (mostly people from our fabulous Security Team):

• Alberto Gonzalez Iniesta
• dann frazier
• Darren Salt
• Devin Carraway
• Florian Weimer
• Gregory Colpart
• Julien Cristau (who is glad that he finally got rid of xfree86)
• Luk Claes
• Martin Pitt
• Michael Koch
• Moritz Muehlenhoff
• Noah Meyerhans
• Patrick Schoenfeld
• Roland Mas
• Russ Allbery
• Sean Finney
• Steffen Joeris
• Thijs Kinkhorst

I would also like to thank dann frazier, Luk Claes, Martin Zobel-Helas and Neil McGovern for helping with the preparation of the point release.